Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Code Review — /code-review (multi-model consensus)

Panel: Claude + 4 OpenRouter models (GPT-5.4, Kimi K2.5, MiniMax M2.7, GLM-5). (Gemini 3.1 errored mid-run; qwen/deepseek/mimo unavailable on the provider.)

Verdict: Request changes (small, targeted). This is a thorough, well-engineered installer with genuine parity to the bash script (AVX2 detection + baseline fallback, version pinning, registry PATH + WM_SETTINGCHANGE broadcast, running-exe .old swap, illegal-instruction retry). A couple of correctness items are worth fixing before merge.

I dismissed two panel findings as incorrect after checking the code: the "irm | iex missing -ExecutionPolicy Bypass" claim is a false positive — installation/index.ts invokes ["powershell","-NoProfile","-ExecutionPolicy","Bypass","-Command", …]; and the "curl.exe needs explicit TLS flags / -k" suggestion is backwards (curl.exe validates TLS by default).

MAJOR — arch detection rejects valid 64-bit machines under 32-bit PowerShell (Bug) — install.ps1 (arch check) — GPT-5.4

$env:PROCESSOR_ARCHITECTURE -ne "AMD64" is wrong under WOW64: a 32-bit PowerShell host on 64-bit Windows reports PROCESSOR_ARCHITECTURE = x86, so a perfectly valid AMD64 machine hits Unsupported OS/Arch: windows/x86 and exits 1. The real architecture lives in PROCESSOR_ARCHITEW6432 in that case. Check both:

$rawArch = if ($env:PROCESSOR_ARCHITEW6432) { $env:PROCESSOR_ARCHITEW6432 } else { $env:PROCESSOR_ARCHITECTURE }
if ($rawArch -ne "AMD64") { ... }

ARM64 is still correctly rejected; this only unblocks the 64-bit-Windows-with-32-bit-pwsh case.

MAJOR (parity) — no integrity verification of the downloaded archive (Security) — install.ps1 (Install-Target) — Kimi, GLM-5

The zip is downloaded and Expand-Archived with no checksum/signature check, and self-update runs irm … | iex. This is real, but it mirrors the existing curl | bash installer's posture, so it's a pre-existing threat-model choice, not a regression introduced here. Worth raising the bar for both installers: if releases publish a checksums file, verify it before extracting —

$actual = (Get-FileHash $zipPath -Algorithm SHA256).Hash
if ($actual -ne $expected) { throw "checksum mismatch for $filename" }

At minimum, call out in the PR that integrity verification is intentionally deferred to match the bash script.

MINOR — nothrow: true may report a failed Windows upgrade as success — installation/index.ts (upgradePowershell) — Kimi

Process.run([...], { nothrow: true }) won't throw on a non-zero PowerShell exit. Confirm the upgrade caller inspects the returned exit code; otherwise a failed self-update silently looks successful and the user never gets the "download a release binary manually" fallback that upgrade() would otherwise notify().

MINOR — malformed "Installed version: ." line — install.ps1 (version probe) — MiniMax

When altimate --version yields empty output, the script prints Installed version: .. Guard the empty case (pre-existing in the bash installer too).

MINOR — tests only assert the script contains substrings (Testing) — MiniMax, Kimi

windows-install.test.ts greps install.ps1 text for expected flags; it exercises no behavior. The riskiest paths — arch/WOW64 detection, AVX2 illegal-instruction retry, -NoPathUpdate, invalid-version rejection — have no behavioral coverage. PowerShell is awkward to run on the CI host, but a Pester smoke test (mocking the Win32 calls) or at least a documented manual check on a real Windows box would de-risk the two MAJORs above. Add negative cases (unknown version → friendly error; -NoPathUpdate/-ForceBaseline honored).

NIT — GLM-5

• No -Help/usage block — the bash installer has usage(); users can't discover -Version/-NoPathUpdate/-ForceBaseline without reading source.
• Two Add-Type P/Invoke blocks land in different sub-namespaces (Win32.AltimateKernel32 vs Win32.NativeMethods) — consolidate.
• Inconsistent error prefixes (Error: vs bare) make log parsing harder.

Positive observations (consensus)

• Strong feature parity with the bash installer; the Windows-specific hard parts are handled well (registry PATH vs setx's 1024-char truncation, WM_SETTINGCHANGE broadcast, renaming the locked running exe before replacing it).
• The self-update wiring is thoughtful: HEAD-probe the install URL first to surface a friendly error instead of an opaque irm | iex failure, and pass the pinned VERSION through env.
• AVX2 detection via IsProcessorFeaturePresent(40) with a baseline fallback + illegal-instruction rescue is a nice touch and matches the bash behavior.

Bottom line: fix the WOW64 arch check (it blocks real users), decide on the checksum question for both installers, and confirm the nothrow upgrade-failure path — then this is a solid Windows on-ramp.

✅ Tested on native Windows (PowerShell 5.1, Win11 x64 AMD64)

Ran the prescribed irm … | iex one-liner against the branch's install.ps1 (raw GitHub URL, since the www.altimate.sh/install.ps1 302 is the noted follow-up and isn't live yet). The irm | iex mechanism is what the redirect will serve once it ships.

Setup: cleared the existing npm-global @altimateai/altimate-code@0.7.3 first → clean slate, no .altimate\bin.

Same-terminal PATH: confirmed the install line $env:Path = "$InstallDir;$env:Path" makes bare altimate resolvable in the same session that ran the one-liner — no refresh needed. New terminals read the registry PATH; only other already-open shells need a fresh window (standard Windows installer behavior).

Not exercised (both by-design, gated on external bits): the AVX2→baseline rescue (this CPU has AVX2 — would need a -ForceBaseline or non-AVX2 box) and the native altimate upgrade dispatch (HEAD-checks the same not-yet-live install.ps1 redirect).

Review remarks addressed (pushed in bb393db)

Thanks all — here's the disposition of every remark.

Fixed

• WOW64 arch detection (MAJOR, @anandgupta42 / GPT-5.4) — install.ps1 now resolves arch via PROCESSOR_ARCHITEW6432, so a 32-bit PowerShell host on 64-bit Windows is correctly detected as AMD64 instead of being rejected as unsupported x86. Covered by new behavioral Pester tests.
• No -Help/usage (NIT, GLM-5) — added -Help switch + Show-Usage mirroring the bash usage().
• Two Add-Type blocks (NIT, GLM-5) — consolidated into one Win32.AltimateNative type (IsProcessorFeaturePresent + SendMessageTimeout).
• Inconsistent error prefixes (NIT, GLM-5) — all user-facing errors now go through Write-Err with a uniform error: prefix.
• Tests only assert substrings (MINOR, MiniMax/Kimi) — added test/windows/install.Tests.ps1 (Pester) running the script as a subprocess to cover syntax, -Help, the WOW64 fix, ARM64/x86 rejection, and unknown-version handling, plus a windows-latest CI lane. 6/6 pass on PowerShell 7.6.2.

Checksum / integrity (MAJOR-parity, @coderabbitai + Kimi/GLM-5)

Releases don't currently publish a checksums asset, so the suggested $url.sha256 fetch would 404 — and the catch { "continuing anyway" } would make it a silent no-op that looks like verification. As @anandgupta42's panel noted, this mirrors the existing curl | bash installer's posture (no regression). I've documented the intentional deferral in install.ps1, and I'm opening a follow-up PR to publish a checksums.txt release asset and verify it in both installers for true parity.

Verified — no change needed

• nothrow upgrade failure (MINOR, Kimi) — upgrade() already does if (!result || result.code !== 0) throw new UpgradeFailedError(...); the PS installer propagates non-zero via exit 1 + $ErrorActionPreference="Stop". A failed Windows self-update is surfaced with the manual-fallback message.
• "Installed version: ." (MINOR, MiniMax) — already guarded by elseif ($installedVersion); empty output prints nothing.
• Dismissed false positives (consensus) — -ExecutionPolicy Bypass is present in installation/index.ts; curl.exe validates TLS by default. Agreed, no action.
• "15 TypeScript failures" (centralized bot) — all in test/altimate/simulation-suite.test.ts + telemetry tests (warehouse/bridge error-mode simulation); this PR touches none of those files. Pre-existing/flaky, unrelated to the installer.

Thanks @ralphstodomingo for the on-box Windows verification. 🙏

Follow-up for the checksum/integrity item is up: #942 (publishes checksums.txt with releases and verifies it in both the bash and PowerShell installers). It's stacked on this branch — merge this first, then #942.

@mdesmet — thorough disposition, thank you. Everything looks good:

• WOW64 MAJOR → Fixed ✅ — the PROCESSOR_ARCHITEW6432 check is the correct Windows-idiomatic fix and the Pester coverage is exactly the right way to lock it in.
• Checksum deferral → Reasonable ✅ — agreed that a catch { "continuing anyway" } wrapping a 404 would be theater, not security. Documenting the intentional parity with the bash installer and tracking it in a follow-up PR is the right call.
• nothrow / "version: ." → Already handled ✅ — the code paths you described (result.code !== 0 check, elseif ($installedVersion) guard) confirm these were false positives on my part.
• Nit fixes ✅ — -Help/Show-Usage, consolidated Add-Type, uniform error: prefix all landed cleanly.
• Pester suite + windows-latest CI lane ✅ — behavioral coverage for the highest-risk paths (WOW64, ARM64/x86 rejection, unknown-version error) is a solid addition.

The 15 pre-existing TypeScript failures are clearly unrelated to this PR.

Everything is addressed. Approving. 🎉

(ﾉ◕ヮ◕)ﾉ*:･ﾟ✧ 🐇

Re-tested on bb393db8 (native Windows, PS 5.1, x64) — ✅ installs, with one robustness note

WOW64 arch fix, -Help, and the consolidated Initialize-Native P/Invoke all look good. Re-ran the full clean flow (cleared the npm global → irm … | iex → verify → idempotency). Install/version/PATH/idempotency all pass, and -Help renders correctly.

One real snag: the first attempt hard-failed:

error: Failed to fetch version information

Root cause was a transient 504 Gateway Timeout from api.github.com on the releases/latest call (confirmed by reproducing the raw Invoke-RestMethod — TLS negotiated fine, GitHub itself returned 504). A retry installed cleanly. The issue is that this single unauthenticated API call is treated as fatal with no retry, so a momentary GitHub blip aborts the whole install — and unauthenticated api.github.com is also rate-limited at 60/hr/IP, so CI or repeated runs can trip it too.

Two cheap hardenings:

1. Retry/backoff around the version-resolve call.
2. Don't hard-depend on the API in the useLatest path. The download already uses …/releases/latest/download/$filename, which GitHub resolves "latest" for server-side — no API needed. The Invoke-RestMethod is only for the version-string display and the "already installed" short-circuit, so it could degrade gracefully (skip the skip-check) instead of exit 1 when the API is unavailable.

Minor, separate: the "already installed" and -Help paths call exit 0, which under irm … | iex runs in-process. Fine for the documented powershell -c "…" child-process form, but pasted directly into an interactive shell it would close the window. (curl | bash exits in a subshell, so the bash installer doesn't have this.) Low severity.

Everything else looks solid for merge once the version-fetch robustness is decided on.

Thanks @ralphstodomingo — confirmed and fixed.

The version-fetch hard-fail is in both installers (install bash:206-213 hits the same api.github.com/.../releases/latest and exit 1s identically). Fixed in a stacked PR: #946.

Both installers now, in the latest path: retry the API call 3× with backoff (bash via curl --fail so a 504 retries instead of parsing the error body), then degrade gracefully — install latest anyway (the download already uses releases/latest/download/..., no API needed) instead of aborting. Pinned -Version/--version still hard-fails on a genuine 404. Also guarded the "already installed" check so an unresolved version can't false-match.

Re the exit 0/irm | iex interactive-window note: agreed it's PowerShell-only (bash exits in a subshell) and only bites when pasted directly into an interactive prompt rather than the documented powershell -c "…" child-process form. Leaving as-is — low severity, no parity gap.

Stacking: #930 → #942 (checksums) / #946 (fetch resilience), both stacked here. I'll rebase the two onto main after #930 lands.

❌ Tests — Failures Detected

TypeScript — 15 failure(s)

• connection_refused [1.00ms]
• timeout
• permission_denied
• parse_error
• network_error
• auth_failure
• rate_limit
• internal_error
• empty_error
• connection_refused
• timeout
• permission_denied
• parse_error
• network_error [1.00ms]
• auth_failure

Next Step

Please address the failing cases above and re-run verification.

cc @mdesmet